In a time-triggered design approach, the recognition of the changes of state of a peripheral device is generally produced through a so-called polling method. One such method consists in defining a task which observes, at successive time intervals, regular or not, the state of a peripheral device and reacts accordingly by activating the corresponding functional processing operations, for example, controlling an actuator on the basis of the data received by the peripheral device.
By construction, in such an approach, there is a delay between a change of state of the peripheral device and the execution of the associated task responsible for observing this change. For example, for a periodic task, this delay is equal, at best, to one times the period of the task. To be able to reduce this delay and therefore increase the responsiveness of the system, a polling approach entails increasing the frequency of activation of the task associated with the management of the state of a peripheral device. This causes the load of the processor on which this task is executed to be increased, and causes this task to be executed on each of its activation loops with no guarantee that a useful operating processing operation will be executed and to overload the application code of this polling management, making it dependent to the underlying system implementation. Furthermore, when a number of polling loops are necessary in the design of a system in order to manage a plurality of peripheral devices, the load problems described previously are increased because of the multiplicity of the necessary execution contexts.
A polling approach therefore induces an increase in the processor power necessary to execute a system. This increase in the load of the processor constitutes the main problem with the use of the polling approach in a time-triggered system and is an obstacle to the reduction of the costs of the systems implemented with this approach.
There now follows a more detailed description of the different technical sub-problems, not resolved when the polling approach is used and targeted by the invention, and the limitations of the prior art with respect to these different sub-problems.
In a time-triggered approach, the temporal constraints of the tasks to be executed are specified in the design of the applications. To be able to specify these temporal constraints relative to a physical time, one possibility is to use instants included in physical clocks. These clocks make it possible to specify activation and termination dates or task deadlines thus defining the triggering, that is to say a series of events described in a physical time base. The interleaving of these tasks can be represented in the form of a series of time intervals, the end of one time interval, and therefore the start of the next interval, corresponding to a date of activation of at least one task.
A time-triggered system defines a single clock domain hereinafter called physical clock domain for which the source interrupt or so-called triggering interrupt is generated by a hardware component, such as a quartz crystal oscillator, making it possible to define the physical time of the real time system. A first technical problem arises when there is a desire to specify, in the physical clock domain, the temporal behavior of tasks as a function of the changes of state of a peripheral device. In effect, the changes of state of the peripheral devices are asynchronous relative to physical clocks and it is therefore not possible to specify their temporal behavior directly in the physical clock domain, that is to say as a function of the internal clock of the main processor. Thus, the use of a polling approach does not make it possible to specify the temporal behavior of a task as a function of the changes of state of a peripheral device. A delay is always present between a change of state and a task activation date.
A set of tasks triggered by the occurrence of an external event defines a clock domain that is asynchronous relative to the physical time, for which the source interrupt originates from the peripheral device linking the system to the outside world. Such an asynchronous clock domain is, hereinafter in the description, called external clock domain. At a given instant, a task is assigned to a single physical, or external, clock domain and an application may be made up of a plurality of clock domains. The existence of different clock domains is present for example in the applications of the type servo controlling the variable speed of a toothed wheel (physical and angular external clock domains, linked to the position of the toothed wheel) or of the type of capture of the value of electrical signals (sampling physical and external clock domains, linked to the measurement of electrical values) and guides the design of some of these applications.
The international patent application WO 2002/39277 is known, which only allows for the implementation of a so-called polling approach for the management of the changes of state of a peripheral device, leading by construction to the presence of a delay between the event and its recognition by the system. Moreover, this patent application does not therefore allow for the design and execution of applications that need to incorporate processing operations whose temporal behavior is specified according to different clock domains including an interrupt management.
Also known is the American patent application US 2004/0117685 which relates to a method for taking charge of asynchronous events in a time-triggered system. This method uses a polling mechanism for the management of asynchronous events and processes these events only in time intervals, executed periodically, which can be defined statically in the design of the applications or allocated to the execution if an asynchronous event is detected. However, even in the latter case, the new allocation of the execution time intervals takes effect only at the end of the current execution period. The instants of changes of state of a peripheral device are not therefore used to specify activation dates and task deadlines and there is therefore a delay between a change of state of a peripheral device and the detection of this change of state, inducing a unnecessary processor load as already explained above.
The publication “Arkadeb Ghosal and Thomas A. Henzinger and Christoph M. Kirsch and Marco A. A. Sanvido, Event-driven programming with logical execution times, Proc. of HSCC 2004, Lecture Notes in Computer Science” also describes a system incorporating asynchronous events in an time-triggered approach. Task activation can be triggered on such asynchronous events, but the termination of a task is always expressed in physical time. Moreover, in this approach, there is still a delay between the occurrence of an event and its recognition because of the need to await the termination of the instances of the (periodic) tasks currently being executed. Thus, the problem of specifying the triggering, that is to say both the activation and the termination of tasks on the basis of asynchronous events relative to the physical time is not resolved by these works.
A second sub-problem of a polling approach lies in the lack of responsiveness to the instant of real execution of the processing operations linked to an interrupt originating from an external clock domain.
If the frequency of activation of a task is not compatible with the cost of the changes of context of execution of this task or/and there is a need for responsiveness to the instant of real execution of the event-linked processing operations (without a concept of deadline), a polling approach is not possible. An interrupt-based mode of operation is then necessary, a technique that is well known to those skilled in the art, making it possible to trigger processing operations following the occurrence of an interrupt.
The international patent application of the applicant published under the number WO 2002/39277 provides a solution to the abovementioned problem through a control of the interleaving of the tasks executed, but is still not applicable if the cost of changing one or more execution contexts is not compatible with the constraint of responsiveness with respect to the processing operations to be executed.
The prior art is rich on the use of mechanisms which make it possible to switch over from a polling-based operation to an interrupt-based operation based on the processor load but these different methods do not target the field of real-time systems. The publication by Jeffrey C. Mogul and K. K. Ramakrishnan, “Eliminating Receive Livelock in an Interrupt-Driven Kernel”, ACM Transactions on Computer Systems, volume 15, number 3, pages 217-252, 1997, is, for example, known.
The method described in the American patent application US 2004/0117685 allows for the production of a response, following the detection of an asynchronous event, at a precise instant, but, for this, relies on particular hardware that makes it possible to delay the transmission of the response. In effect, no guarantee can be provided as to the fact that the asynchronous response event will have to be executed without a time interval dedicated to the management of asynchronous events. Moreover, the method described is comparable to the known concept of “polling server” and “bandwidth-preserving server” in the real-time systems, but which does not make it possible to execute a processing operation at a precise instant, only to minimize a delay between the occurrence of an event and the execution of the functional code linked to that event.
A third sub-problem targeted by the invention relates to the communication between different tasks which are triggered according to different clock domains.
An application can be made up of tasks belonging to different clock domains and a task of one domain may want to communicate with a task of another domain and/or await an event that might be outside of its clock domain. Such events notably include:                events associated with instants expressed using other clock domains, for example an instant expressed in angular clock mode for a task for which the clock is in real time, or, conversely, an instant in real time for a task for which the clock is in angular time. For example, it may concern the sending of data by a task to another clock domain, or, for a task of a physical clock domain, the occurrence of the next interrupt of an external clock domain;        asynchronous events, for example the arrival of an interrupt triggered by the activation of an indicator control by the driver of a car, even if these events are not associated with any clock of a clock domain;        